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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 



Background 



Time Stamping is critical for electronic signatures in order to know whether the digital signature was affixed during the 
validity period of the certificate. To this respect, electronic signatures must be time stamped during the life time of the 
corresponding certificate. 

A Time Stamp Protocol (TSP) has been defined by the IETF. The present document limits the number of options by 
placing some additional constraints. 
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1 Scope 

The present document is based on the Time Stamp Protocol (TSP) from RFC 3161 [1]. 

It defines what a Time Stamping client must support and what a Time Stamping Server must support. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] IETF RFC 3161: "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". 

[2] FIPS Publication 180-2 (2002): "Secure Hash Standard (SHS)". 

[3] Void. 

[4] IETF RFC 1321 (1992): "The MD5 Message-Digest Algorithm". 

[5] IETF RFC 3447: "Public-Key Cryptography Standards (PKCS) #1 : RSA Cryptography 

Specifications Version 2.1". 

[6] ISO/TEC 10118-3: "Information technology - Security techniques - Hash-functions - Part 3: 

Dedicated hash-functions". 

[7] ISO 9594-6: "Information technology - Open Systems Interconnection - The Directory: Selected 

attribute types". 

[8] ITU-T Recommendation X.520: "Information technology - Open Systems Interconnection - The 

Directory: Selected attribute types". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Message Digest 5 (MD5): one way hash function that provides an 128 bits output 

Race Integrity Primitives Evaluation Message Digest 160 (RIPEMD-160): one way hash function that provides a 
160 bits output 

Rivest Shamir Adleman (RSA): algorithm usable either for signature or encryption 

Secure Hash Function l(SHA-l): one way hash function that provides a 160 bits output 

time-stamping unit: set of hardware and software which is managed as a unit and has a single time-stamping signing 
key active at a time 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

DSA Digital Signature Algorithm 

NOTE: A signature algorithm used in conjunction with SHA-1. 

HTTP HyperText Transfer Protocol 

MD5 Message Digest 5 

PKCS Public Key Cryptographic Standards 

NOTE: Standards published by RSA, Labs. 

RIPEMD-160 Race Integrity Primitives Evaluation Message Digest 160 
RSA Rivest Shamir Adleman 

SHA-1 Secure Hash Function 1 

TSA Time Stamping Authority 

TSP Time Stamp Protocol 



4 Requirements for a TSP client 

4.1 Void 

4.2 Profile for the format of the request 

4.2.1 Parameters to be supported 

The following requirement applies: no extension field shall be present. 

4.2.2 Algorithms to be used 

The following hash algorithms may be used to hash the information to be time-stamped: SHA-1, MD5, RIPEMD-160. 
It is recommended to use either SHA-1 or RIPEMD-160. 

4.3 Profile for the format of the response 

4.3.1 Parameters to be supported 

The following requirements apply: 

• the accuracy field must be supported and understood, 

• the nonce parameter must be supported, 

• no extension is required to be supported. 

NOTE: A TSA may not support ordering hence clients should not depend on the ordering of time-stamps. 

4.3.2 Algorithms to be supported 

The following signature algorithm must be supported: 

• SHA-1 with RSA. 
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4.3.3 Key lengths to be supported 

For the RSA algorithm, key lengths of 1 024 bits must be supported. Key lengths of 2 048 bits should be supported. 
For the DSA algorithm, the larger of the two primes, p and q, shall be at least 1 024 bits. 

5 Requirements for a TSP server 

5.1 Profile for the format of the request 

5.1 .1 Parameters to be supported 

The following requirements apply: 

• the nonce must be supported, 

• certReq must be supported, 

• no extension is required to be supported. 

5.1 .2 Algorithms to be supported 

The following hash algorithms must be recognized: SHA-1, MD5, RIPEMD-160. 

5.2 Profile for the format of the response 

5.2.1 Parameters to be supported 

The following requirements apply: 

• a genTime parameter limited to represent time with one second is required, 

• a minimum accuracy of one second is required, 

• an ordering parameter missing or set to false is required, 

• no extension is required to be generated, 

• no extension shall be critical. 

5.2.2 Structure for the name of the issuing TSP server 

The name of the issuing TSP server shall contain an appropriate subset of the following attributes (defined in 
ISO 9594-6 [7] and ITU-T Recommendation X.520 [8]): 

• countryName; 

• stateOrProvinceName; 

• organizationName; 

• commonName. 

The countryName, when applicable, identifies the name of the country where the TS A is established 
(which is not necessarily the name of the country where the time-stamping unit is located). 

The stateOrProvinceName is an optional component that identifies a geographical subdivision in which the TSA is 
established. 
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The organizationName shall be present. It identifies the TSA responsible for managing the time-stamping unit. That 
name should be an officially registered name of the TSA. 

The commonName shall be present. It specifies an identifier for the time-stamping unit. Within the TSA, 
the attribute commonName uniquely identifies the time-stamping unit used. 

5.2.3 Algorithms to be supported 

The following hash algorithms must be supported: SHA-1, MD5, RIPEMD-160. 
The following signature algorithm must be supported: 

• SHA1 with RSA. 

The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding 
conventions described in PKCS #1, RFC 3447 [5]. 

5.2.4 Key lengths be supported 

For the RSA algorithm, key lengths of 1 024 bits must be supported. Key lengths of 2 048 bits may be supported. 

6 Profiles for the transport protocols to be supported 

One on-line protocol and one store and forward protocol must be supported for every Time Stamping Authority (TSA). 
Among the four protocols that are defined in the RFC 3161 [1], the following protocol should be supported: 

• the Time Stamp Protocol via HTTP (section 3.4 from the RFC 3161 [1]). 

7 Object identifiers of the cryptographic algorithms 
7.1 Hash algorithms 

7.1.1 SHA-1 

The SHA-1 digest algorithm is defined in FIPS Pub 180-2 [2]. The algorithm identifier for SHA-1 is: 

sha-l OBJECT IDENTIFIER ::= { iso(l) identif ied-organization (3 ) oiw(14) secsig(3) algorithm(2) 26 } 

The Algorithmldentifier parameters field is optional. If present, the parameters field shall contain an ASN.l NULL. 
Implementations should accept SHA-1 Algorithmldentifiers with absent parameters as well as NULL parameters. 
Implementations should generate SHA-1 Algorithmldentifiers with NULL parameters. 

7.1.2 MD5 

The MD5 digest algorithm is defined in RFC 1321 [4]. The algorithm identifier for MD5 is: 

md5 OBJECT IDENTIFIER ::= { iso(l) member-body (2 ) us(840) rsadsi ( 113549) digestAlgorithm (2 ) 5 } 

The Algorithmldentifier parameters field shall be present, and the parameters field shall contain NULL. 
Implementations may accept the MD5 Algorithmldentifiers with absent parameters as well as NULL parameters. 
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7.1.3 RIPEMD-160 

The RIPEMD-160 digest algorithm is defined in ISO/IEC 10118-3 [6]. 

Information about RIPEMD-160 can also be found in the following publications (see bibliography): 

• "RIPEMD-160, a strengthened version of RIPEMD"; 

• "Handbook of Applied Cryptography" ; 

• "The RIPEMD-160 cryptographic hash function"; 

• "The cryptographic hash function RIPEMD- 1 60" . 

At the time of publication of the present document, this information was available at the following address: 

http://www.esat.kuleuven.ac.be/~bosselae/ripemdl60.html#Outline 
The algorithm identifier for RIPEMD-160 is: 

{ iso ( 1 ) i dent if ied-organization (3) teletrust (36) algorithm (3) hashAlgorithm (2 ) ripemdl60 (1) } 

7.2 Signature algorithm 

The RSA signature algorithm is defined in RFC 3447 [5], RFC 3447 [5] specifies the use of the RSA signature 
algorithm with the SHA-1 and MD5 message digest algorithms. 

When the hash function to be used is SHA-1, then the OID should be: 

shalWithRSAEncryption OBJECT IDENTIFIER ::= { iso(l) member-body (2 ) US (840) rsadsi ( 113549) 
pkcs(l) pkcs-l(l) 5} 
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Annex A (informative): 
Structure for the policy field 



When the TSA conforms to TS 102 023, then the policy field from the TSTInfo structure should contain the identifier 
for the baseline time-stamp policy defined in the present document, which is: 

itu-t(O) identif ied-organization (4 ) etsi(0) time-stamp-policy (xxxx) 
policy-identif iers (1) baseline-ts-policy (1) 

If this identifier is not included, a TSA may define its own policy which enhances of this policy. 
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